Migrating to Prizm Application Services (PAS)

For existing customers of PCC who have already done the work to integrate the viewer into their applications, there is naturally a question about how to, and perhaps more importantly, why migrate to the new PAS architecture.

The first thing to know about PAS is that there is no requirement that your application migrate to use it. PAS makes use of the same RESTful API that your application currently supports, and that won’t change in the future (although we will likely augment this API over time to include more functionality).

However, there are several strong reasons why it’s beneficial to make the switch and use PAS:

You will know that your application always has the canonical approach to working with the viewer. No wondering about any odd nuances in the REST APIs that you might be missing.
PAS will always incorporate any changes to the APIs used by the PCC back-end conversion services, relieving your team of having to track those changes for most document viewing tasks.
Migrating to PAS will actually remove significant code from your application, which will reduce your future maintenance costs.
And perhaps most importantly: we have several ideas on how to utilize PAS to add significant functionality to the overall PCC experience, some of which we’re working on already. Without incorporating PAS in your application, you will not be able to take advantage of these new features.

How to Migrate to PAS

The work needed to migrate your application to PAS can range from simply overriding several routes in your web server’s configuration to having to override several functions from the PAS implementation and redirecting them to your own. See which one of the following scenarios best explains your situation:

Scenario 1

If your application has used the web sample code we’ve provided in the past without modifications, then the migration path is simple: install PAS and see the help article on how to configure it for your particular web server.

Scenario 2

If you are using a custom storage mechanism for your documents, but not markup files, you might be in a situation where you are using a custom markup id when creating a session. In the previous samples, this is the value of origin.documentMarkupId. If this is the case, you can update your code for creating a session to use the PAS ViewingSession API instead of interacting with the back-end services. You can provide the same value to source.markupId, allowing PAS to use the same custom ids you have used in the past. For more information, see the PAS Viewing Session API.

Scenario 3

Things begin to get more complicated if you’ve implemented your own storage mechanism for annotations and/or image stamp files. While PAS will be backward compatible with these files when created by our web samples, there’s no way for it to know how you’ve stored your own documents. In this case the only recourse is to override the appropriate calls into PAS with calls to your own code to handle persistence.

Note that even in this scenario you can take advantage of most of PAS functionality, as you’ll only be overriding a few functions at most.